home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 1⁄12⁄90 / 0035-Re[2] What Gives He-Jan90 < prev    next >
Encoding:
Text File  |  1990-01-12  |  4.4 KB  |  102 lines  |  [TEXT/GEOL]
  1. Item    1145388                         9-Jan-90        20:11
  2.  
  3. From:   D3632                           Cadence Design, Ken Friedenbach,PRT
  4.  
  5. To:     NASSI                           Nassi, Ike
  6.         SCHMUCKER1                      Schmucker, Kurt
  7.         CPLUS.APPLE$                    C++ Interest List--Apple Employees
  8.         CPLUS.DEV$                      C++ Interest List--Developers
  9.  
  10. Sub:    Re-Re- What Gives Here?
  11.  
  12. Kurt, Gary, Ike,
  13.  
  14. Part of "What gives here?" is bugs in the current implementation, and part is
  15. weaknesses in the language definition.  Pure virtual functions were added very
  16. late in the development cycle for cfront 2.0.  So was the logic for checking
  17. for "hiding" errors.  These two language features are not fully integrated yet.
  18.  
  19. NOTE:  There are other parts of the current compiler which do not fully "know"
  20. about pure virtual functions, such as destructors.  Attempting to declare a
  21. pure virtual destructor results in a link error, when a derived class
  22. destructor attempts to call the (non-existent) base class destructor.
  23.  
  24. If you omit the keyword "virtual" everywhere in your example, then "things work
  25. O.K.".  For example, the following does not generate any compiler warnings:
  26.  
  27. ----------
  28.  
  29. class A {
  30.     void foo(int& i) ;
  31.     void foo(char& c) ;
  32. };
  33.  
  34. class B : public A {
  35.     void foo(int& i);
  36.     void foo(char& c);
  37.     void foo(float& f);
  38.     void foo(double& d);
  39. };
  40.  
  41. class C : public B {
  42.     void foo(float& f);
  43.     void foo(double& d);
  44. };
  45.  
  46. -------------
  47.  
  48. (Of course, it is probably a "BUG" to be trying to override non-virtual
  49. functions, but that is another, bigger language design issue.  Should a
  50. language force a user to do "reasonable" things?  Or, in the interest of "full
  51. orthogonality", allow a little non-sense along with the sense?)
  52.  
  53. The warnings about "hiding" virtual functions is an attempt to cure a language
  54. design weakness with an ad-hoc mechanism for generating warnings.  The weakness
  55. is caused by the looseness regarding the keyword "virtual", which is required
  56. for the first declaration of a virtual function in a base class, but can be
  57. omited for derived classes.
  58.  
  59. This leads to several types of "architecture errors" which cannot be detected
  60. by a C++ compiler:
  61.     1.  Inadvertant matching of a user function with a virtual function in a
  62. library base class.  (The user causes an unexpected "replacement" of a base
  63. class function.)
  64.     2.  Inadvertant mis-matching when a user attempts to override an existing
  65. function, but makes a spelling or type matching error.  (The user get an
  66. unexpected "new" function, which can be either virtual or non-virtual,
  67. depending on whether or not the user opted to use the "virtual" keyword.)
  68. Mis-matches can be caused by spelling errors, inconsistant use of "const" or
  69. "unsigned", or other "minor" type mis-matches.
  70.  
  71. The weakness of the language in this area was worsened in Version 2.0 which has
  72. automatic "overloading".  Prior to Version 2.0, the keyword "overload" had to
  73. be used.
  74.  
  75. The "best" solution to the language weakness would be to use the keyword
  76. "override" for derived classes.  There are two ways override could be defined:
  77.     1.  Weak semantics:  allow override.  Check that a match occurs if the
  78. keyword override is used.  Otherwise, fall back to the current rules.
  79.     2.  Strong semantics:  require override.  Check that matches do not occur
  80. if override has not been specified.  Give an error if "virtual" is used a
  81. second time, or nothing is said for a match.
  82.  
  83. Only the Strong semantics will catch all the errors mentioned above.
  84.  
  85. Bjarne has indicated that he is not going to implement override, and the issue
  86. should be directed to the ANSI C++ Standards Committee for consideration.
  87.  
  88. Note:  There are other language design issues lurking here!  In your example,
  89. the use of references makes all the types distinct.  But what about C's rules
  90. for "widening" chars and shorts to int? or float and double to extended?  And
  91. what about signed or unsigened vs. "plain" int?  And what about "char const *"
  92. and "char * const" and "char const * const" as opposed to "char *"?
  93.  
  94. Given the great number of distinct types in C (and C++), and the various rules
  95. for "converting", "widening", etc. it was probably a good idea to give
  96. "warnings" for overloadings which are "too close".  Whether the rule about
  97. "overriding is stronger than overloading" implements this idea or not is
  98. debatable.  And limiting the check to virtual functions seems like a mistake.
  99.  
  100. Ken
  101.  
  102.